OpenWest 2017 - Passing the Baton: Succession Planning for FOSS leadership

Passing the Baton

Succession planning for FOS

leadership

A

OpenWest 2017

»

/

f> \

0 v

@vmbrasseur

\

@vmbrasseur, CC BY-SA

VM (Vicky) Brasseur

& @vmbrasseur
? vmbrasseur

p openwest@vmbrasseur.com

@vmbrasseur, CC BY-SA

2

Freelance open source business strategy consultant

Author & community moderator for
opensource.com

Slides:

https ://archive.org/details/
openwest20 17-
successionplanning

@vmbrasseur, CC BY-SA

YMMV

@vmbrasseur, CC BY-SA

Succession planning can be a complicated thing at times.

I will be presenting general tips for how to approach this
process.

Not all of the recommendations will necessarily apply to
your specific situation.

For instance, some of the recommendations may apply
better to large projects, others to small projects. It all
depends on the project in question & its special needs.

Take from the presentation what you need. Don't feel
obligated to follow every suggestion to the letter.

Please save questions for
the end

@vmbrasseur, CC BY-SA

5

I've built in time at the end to make sure we have time to
cover your questions.

But please save them for the end. Don't worry: well have
time.

Brief history of FOSS

@vmbrasseur, CC BY-SA

Let's set some context.

A We've been sharing software for as long as there'
BEEN software

A But free/open software as a recognizable
movement only started 40 years ago.

A Let's quickly look at some of the many highlights
of our history.

1970s & 1980s

- 1976: emacs

- 1983: GNU

- 1984: X

- 1985: FSF

- 1987: Perl

@vmbrasseur, CC BY-SA

7

emacs: Moon & Steele
A GNU, FSF: RMS
A X: Gettys & Sheifler at MIT
A Perl: Created by Larry Wall, whom if you
haven't met I recommend you do as he may just
be the nicest, kindest man in all of technology

Note also: Perl is 30 years old this year!
Congratulations!

1990s

— 1991: Linux, Python

— 1993: NetBSD, FreeBSD

— 1995: PHP, GIMP, Ruby

— 1996: Apache, KDE

— 1997: GNOME

— 1998: "open source" coined, OSI formed

— 1999: OpenOffice, Apache Software Foundation

@vmbrasseur, CC BY-SA 8

Things started getting really exciting in the 1990s.

A Aside from all of the above, the open software team at Sun
Microsystems was doing some stellar fundamental work on what
later became open source software and the movement around it.

2000s

— 2003: Mozilla, Wikimedia

— 2004: Ubuntu

— 2005 : git

— 2006: Software Freedom Conservancy

— 2007: OpenJDK

— 2008: Chromium, Android

— oh so many more things

@vmbrasseur, CC BY-SA 9

A new century brought an explosion of free and
open source software and organisations.

A Things have really escalated in the past 10 years.
A FOSS components have become the default
selection for many companies

We've come of age

@vmbrasseur, CC BY-SA

"Software has eaten the world & open source has eaten
software" is a phrase I've seen trotted out.

While I don't really agree with it, there's no denying that the free
and open source software movements have changed the face
of technology & are here to stay.

...and we're starting to reach the scale and age where oral
history doesn't cut it anymore.

40 years. 40. And we still have the founders of our movement
in our midst. But for how long?

There are now millions of free
and open source projects
currently in existence...

@vmbrasseur, CC BY-SA

11

According to the 2016 Octoverse, there are over 19.4
million publicly available repos on Github ALONE

. . .we rely on them every day. . .

@vmbrasseur, CC BY-SA

12

Many of us could not do our jobs without these projects. We
couldn't run our companies. We couldn't serve our customers.

...so what happens when their
leaders move on?

@vmbrasseur, CC BY-SA

13

But now, 40 years on, we're overdue to be thinking about how we in
FOSS will get by when our founders, our leaders, move on.

These aren't necessarily the bit RMSs and BDFLs of the world. Every
project has people in important roles. Every project needs to consider
backup plan for when those people leave the project for some reason.

Succession

Planning

@vmbrasseur, CC BY-SA 14

And that brings us to succession planning.

I've done a lot of research into this in a FOSS context,
including surveying and interviewing leaders and community
members of open source projects and communities.

First I'd like to define Succession Planning for y'all so we're
all on the same page.

Defined

"Succession planning is a process for identifying and
developing new leaders who can replace old leaders when
they leave, retire or die." Wikipedia

@vmbrasseur, CC BY-SA

15

This is the Wikipedia definition. It's pretty standard for what you
find in the literature about this subject.

The thing is, I'm not a big fan of this. It's rather limiting. It implies
only "leaders" are the ones who need backup & successors.

And what is a "leader" for FOSS, anyway? When you stop to
think about it, it gets complicated pretty quickly.

L e ad e rship Skills Pipeline

Training and mentoring people in the skills required to
step into important roles.

@vmbrasseur, CC BY-SA

16

Literature focuses on high level leadership things like
CEO, Founder, etc.

This is FOSS. There are other important roles beyond
project founder. Benevolent Dictator for Life.

Any project role which is measured by bus factor is a role
which can benefit from succession planning.

Important to note here that these are Skills, and as Skills
they can be learned.

Why does it matter?

@vmbrasseur, CC BY-SA

Some of you out there are nodding along, "Yes, we should think
about this."

Others are all, like, "Meh, we've never done this in the past. Why
should we think about it now?"

Well, for starters, "we've always done it this way" is a very
dangerous statement. But there are some other reasons why you
should think about succession planning...

Continuity

@vmbrasseur, CC BY-SA

18

The most obvious reason. When someone leaves, what
happens to the tasks they were performing?

They were keeping some plates spinning. When they
leave, do those plates fall and break?

Succession planning helps ensure tasks continue to be
performed and no one is left hanging.

Avoid a power vacuum

@vmbrasseur, CC BY-SA

19

If a person leaves a role without a replacement, it can lead to a
lot of confusion, delays, and possible political woes for the
project.

Those political woes can be the most damaging to a group.
Delays are more easily fixable than hurt feelings.

Creating a succession plan can help alleviate the very insecure
and unstable time when someone in a vital role moves on.

There's no need for people to jockey for position quickly.
Everyone knows who's next in line and why.

Project/organisation longevity

@vmbrasseur, CC BY-SA

20

The thinking required for succession planning is the sort of
thinking which contributes to project longevity.

The entire point of succession planning is that the group is taking
the long view. By definition, you're thinking about longevity.

Ensuring continuity in leadership, culture, productivity also helps
to ensure that the project will continue. It will evolve, but it will
survive.

Reduce load/pressure on current leaders

@vmbrasseur, CC BY-SA

21

Successor becomes backup
A Leaders are more free to take vacations, etc.
A Reduces burnout of project leaders & those
in important roles

Talent development

@vmbrasseur, CC BY-SA

22

Lately we talk about mentoring a lot in FOSS communities, but it's
usually in the context of how to contribute code

We can also mentor people to become successors for critical
roles

This helps everyone: leaders get successors, project/organisation
gets continuity, successors get career development and
experience.

Inspiration/motivation for new members

@vmbrasseur, CC BY-SA

23

Along those lines, it can be very motivational for new
community members to see a succession plan in action.

"There is a path to and plan for leadership positions here.
That could be me some day. I would like to stick around."

Also instills confidence that the project has its shit
together.

Diversity of thoughts/Get out of a rut

@vmbrasseur, CC BY-SA

24

Succession plans are a great opportunity to bring new
people, new ideas into the leadership roles of a project.

Studies show that diverse leadership teams are more
effective and the projects they lead are more innovative.

Use your succession planning as an opportunity to open
the door to diversity.

Truly meritocratic

@vmbrasseur, CC BY-SA 25

iviai ly \j 1 Ujcuio 11 1 1 woo aic |ji uuu ui u 1011 1 1 101 1 luui auy.

Conceptually, it's a good idea.

Unfortunately what passes for meritocracy typically translates to
hostility toward new contributors and echo chambers.

If you can't express what "merit" is beyond "HI know it when I see it"
then you have not thought your vaunted principles through very well.

A meritocracy without a mentoring program and healthy goverance
structure is just an excuse to practice subjective discrimination. It's a
way for bullies to hide behind unexpressed biases.

IMO, you cannot value "merit" if you do not take the time to train
people to earn that merit or even teach them what it is that earns
them that merit.

A well-executed succession plan can help with this.

A well-executed succession plan is open, honest, documented.

Summary of Benefits of Succession Planning

— Continuity

— Avoid a power vacuum

— Project/organisation longevity

— Reduce pressure/load on current leaders

— Talent development

— Inspiration/motivation for new members

— Diversity of thoughts/Get out of a rut

— Truly meritocratic

@vmbrasseur, CC BY-SA 26

As you can see, there are a lot of really great things
which can come from having a succession plan.

It's not a panacea. There will still be problems. But
there are a lot of really worthwhile benefits here.

Despite that, very few FOSS projects or
organisations put much thought into it.

Why?

Why it doesn't happen

@vmbrasseur, CC BY-SA

27

From my research, I've found the following reasons for why
projects don't engage in succession planning:

Too busy

@vmbrasseur, CC BY-SA

28

A lot of people recognized succession planning as a problem in their
project but just "hadn't gotten around to it" because there's "always
something more important to work on."

While I can understand this, I really can, I personally think this is more a
problem with prioritization than with time availability.

It's likely these people may not yet realise how bad it can be not to have
succession plan when you need one. And that's why I'm talking to you
today.

Don't think of it

@vmbrasseur, CC BY-SA 29

Some are just so busy & preoccupied that they haven't even thought about, "Hey, what
would happen if Sarah left the project?" It just never occurs to them. I mean, Sarah's
always there when we need her, right? Always.

Don't want to think of it

@vmbrasseur, CC BY-SA

30

Succession planning is often, like estate planning, associated with negative feelings like
loss and can make people address their own mortality. Some people aren't comfortable
with this and avoid it.

Attitude of current leaders

@vmbrasseur, CC BY-SA

31

Current leaders don't want to recognize that they're replaceable
or to consider that they might give up their power and influence.

Failure to recognise or admit this can set the project up for
failure in the long run.

This doesn't happen often but it does happen and is worth
mentioning.

Don't know where to start

@vmbrasseur, CC BY-SA

32

Some know it should happen,

A are willing to carve out the time,
A but don't know how to do it.

How to develop FOSS
leaders of the future

@vmbrasseur, CC BY-SA

33

OK, so how do you do this? How do you even get started?

DON'T PANIC

@vmbrasseur, CC BY-SA

I'm about to throw a lot at you.

DO NOT feel you have to do it all or do it immediately.

This is a process. Again, the thing about succession
planning is you're taking the long view. That means it
can & should take time.

So don't worry if you don't feel you're making progress.

If you're working on it at all, you ARE making progress.
Congratulations.

Also, I'll give suggestions not just for current leaders, but
also for those who would like to move into critical roles.

Current leaders

@vmbrasseur, CC BY-SA

35

So, if you're currently in a critical role in a project, what can you do
to help cultivate people to take your position when you move on?

Don't work in isolation; work on this together &
publicly

@vmbrasseur, CC BY-SA

36

First of all, remember that you're in an open community
and do all of your work in the open

Solicit feedback from the community and keep them
posted on what's happening and why

Identify critical roles

@vmbrasseur, CC BY-SA

Step one is to identify those roles in your project which
are fairly critical.

You can look at other projects to get an idea of where to
start, but...

Only you & your project can define what qualifies as
"critical" to you.

Role != Person

@vmbrasseur, CC BY-SA

38

Note: While it helps to start by looking at the people on the team, it'
not always to correct that each person is performing only one role

Identify role duties & responsibilities

@vmbrasseur, CC BY-SA

39

Now, once you've identified those roles, be very
honest with yourself and your community about
the duties of each role.

List what you think the role should do

but also list those duties it ACTUALLY performs.

Be honest about the duties a person is performing
and how they might belong to multiple roles

Refactor large roles

@vmbrasseur, CC BY-SA

40

If a role does a LOT, then you should break it up into multiple
smaller roles

Refactor: redistribute roles amongst other people -> Reduce bus
factor right there

Refactoring also makes it much less intimidating for someone new
to take on the role. The new role will be smaller and easier to step
into.

Knowledge transfer

@vmbrasseur, CC BY-SA

Once you've identified the roles, a lot of the work
consists of knowledge transfer

While this should be an on-going process, but you'll
probabsly need a big initial brain dump

once you've collected the initial information it should just
be a matter of sharing it and maintaining incremental
updates.

So what knowledge should you be sharing?

Procedures & processes

@vmbrasseur, CC BY-SA

42

All those duties don't occur in a vacuum. How
does one perform them?

Some may be self-evident. Others may not.

But remember: you have a different perspective.
Self-evident to you isn't to others.

So please be explicit and transfer all knowledge
about all procedures & processes.

Resources

@vmbrasseur, CC BY-SA

43

List of accounts: What accounts exist out there? Travis?
Twitter?

List of contacts: Do you have meetups? Who are the people
who usually help you with meeting space, sponsorship?

Credentials

@vmbrasseur, CC BY-SA

44

No one person should ever have access to credentials
for services used by the project.

This is one of the most common issues faced by
projects when faced with a succession situation

People walk away with the keys and no one else has
copies

I've also seen this power used for evil (shutting folks out,
embezzling, etc)

Always use role email accounts sent to multiple people,
not individual/personal accounts.

Project history

@vmbrasseur, CC BY-SA

45

I swear, my next talk may be on the importance of
history.

For the love of dog, please make sure that everyone is
aware of project history.

This provides the context necessary to make the best
decisions in the operation of duties.

Limit tenure for a role

@vmbrasseur, CC BY-SA

46

Ensure that it will be handed off

Give current role-holder a light at the end of the
tunnel

Ensure there will be a body of people familiar
with the role (past role holders)

DOCUMENT

ALL

THESE

THINGS

@vmbrasseur, CC BY-SA

Now, you've determined & discussed all these things.

I mean, this has probably taken a LOT of a lot of peoples'
time, amiright?

FOR PETE'S SAKE, WRITE THEM DOWN. Don't lose this
information.

The How & Where doesn't matter nearly as much as the
Whether.

Capture this information for posterity. This is a talk on
succession planning. For crying out loud, think of future
generations of project leaders and write this stuff down now.

But consider tl;dr docs

@vmbrasseur, CC BY-SA

Can be helpful to provide an overview doc (more bite-
sized)

New leaders

@vmbrasseur, CC BY-SA

49

So don't think this only has to be the purview of those
already in critical roles.

Those of you who are interested in contributing at a
higher level can do a lot to help this process.

Look for opportunities to learn & contribute

@vmbrasseur, CC BY-SA

50

For starters, look around. Where can you help those in
critical roles?

Are there opportunities for you to learn more about the
leadership and operation of the project?

I can almost guarantee the answer to that question is
"hell yes."

Ask to chip in. Volunteer for the small, possibly
annoying, but definitely important tasks.

Volunteering for the grunt work is a great way to
apprentice your way into a leadership position.

Shadow those in critical roles

@vmbrasseur, CC BY-SA

51

Another way to learn and apprentice your way into
one of these critical roles is to ask whether you might
shadow one of these role-holders.

See how the role is performed. What is the process &
procedure?

See what's actually involved with the role.

Confirm whether you actually want to perform the role.

Ask for mentorship

@vmbrasseur, CC BY-SA

52

We who mentor.. .we're human & we're busy. We don't
always have the mental cycles to recognise that
mentoring it needed or wanted.

We're usually happy to provide it, but sometimes we
need a nudge. Please ask!

Related to that, when you see someone performing
critical duties, ask whether they'd be willing/able to
teach you about it.

Ask for feedback on tasks you perform.

Ask for tasks you might perform to assist them.

Learn the history of the project/organisation

@vmbrasseur, CC BY-SA

53

Sit around the campfire with the project elders & listen to
them spin yarns of the Good Old Days

Extra points: write what you learn and share it for the
benefit of your entire community

Examples of projects
working on this

I

@vmbrasseur, CC BY-SA

54

Was going to give examples of projects doing this
badly but won't for 2 reasons:

1. 1 don't believe in naming-shaming for stuff like this.
A 2. My research shows I don't need to give
examples of projects handling this badly because
everyone already knows some.

Instead, I'll give you examples of projects doing this
well.

Please note: This is not an exhaustive list.

Exercism

https ://exercism.io

"The goal, of course, is to have at least three active
maintainers for every single language track. This way we
could put some procedures into place to mentor new
contributors, nominate new maintainers, and to roll off the
project without any sort of guilt when you no longer want
to maintain a project . "

@vmbrasseur, CC BY-SA

55

Over 60 language tracks, 35 active on the site

Rated their tracks by how maintained they were.

Making very active efforts to make sure each track
has not one, but multiple maintainers

Succession planning in action: always someone
available to step in when one of the maintainers
isn't available.

Gives maintainers breathing room & a chance to
take a break when they need it.

Vox Pupuli

https ://voxpupuli . org

" One of the benefits we hope to achieve is that by a shared
ownership of modules we no longer end up in situations
where the original maintainer has moved on and a forest
of disparate forks try to fill the void."

@vmbrasseur, CC BY-SA

56

Ensure continued development of Puppet
modules

123 repositories of Puppet modules

Image Credits

— Title slide: joohander on Flickr, CC BY-NC.

— Twitter icon: Andrey Vasiliev from the Noun Project

— IRC icon: Gregor Cresnar from the Noun Project

— Email icon: Mackey Guenther from the Noun Project

@vmbrasseur, CC BY-SA

57

Next slide is the SeaGL CFP pitch! Be ready for that!

Please CFP to
SeaGL!

http://seagl.org

Seattle, WA - October 6-7
#seagl on Freenode IRC

@vmbrasseur, CC BY-SA

Seattle GNU/Linux

SeaGL is a great community-organised polyglot/
polytech conference happening in October.

CFP is open now!

Are you presenting at OpenWest? Are you
inspired by anything you've heard at OpenWest?

Same sorts of topics welcome at SeaGL! We
love new speakers, too, & do whatever we can
to make them successful.

Inin i iq nn IDP f nr PPD holn ^nrl incnir^tinn

Slides:

https ://archive.org/details/openwest20 1 7-
successionplanning

Feedback!

https ://www.openwest.org/schedule/#talk- 140

@vmbrasseur, CC BY-SA 59

Reminder: Slides available now. Screencast available
soon.

Also: Please rate this talk & provide feedback! Please!

Now, any questions but not comments disguised as
questions?